|
 |
> Nicolas Alvarez <nic### [at] gmail is the best com> wrote:
>> Another is "changing a
>> previously-defined translate" (that's not currently possible in SDL, and
>> it's a bad idea anyway).
>
> Somehow I feel you are a bit talking about apples and oranges here.
>
> Of course there's no way of "changing a previously defined translate"
> because there's no such thing as a "previously defined translate". As I
> said in the other post, a translation is not a property of the object,
> it's an operation applied to the object (in other words, in object-oriented
> terms, a translation is not a member variable of the object, it's a member
> function). You either apply it (so that it has some effect) or you don't.
> You can't go "back in time" and apply it in a different way once you have
> applied it already.
>
> (Technically speaking you can later apply a new set of transformations
> which cancel out the earlier translation, so the effect is the same as if
> the earlier translation had not been performed at all, but this is a
> rather different thing at a basic conceptual level.)
>
> I can't really see what is the problem people are seeing here. I don't
> see any problem in objects in the new SDL having transformation functions
> which work in the same way as in the current SDL.
>
I was just commenting on Patrick's examples which showed changing
individual transformations, stored in some sort of array. So we are
agreeing. The way transformations should work is the way they currently do.
Post a reply to this message
|
 |